The goal of attaining an integrated video/graphics system requires a system architect to balance often conflicting requirements of video subsystems and graphics subsystems. For example, while increasing horizontal and vertical resolution is beneficial to graphics images, in digital video subsystems increasing horizontal and vertical resolution can actually be detrimental to the overall image quality. Likewise, in graphics subsystems, the pixel depth, i.e. the number of simultaneous colors available, is not as important as it is for video systems. While it may be hard to justify the additional system cost of 16 bit, near-true-color pixels for the graphics system, a video system can arguably make use of deeper 24 bit pixels.
The performance budget of a video processor in a digital video subsystem during playback is divided and used to perform two tasks: creating the video image from a compressed data stream and copying/scaling the image to the display buffer. The performance budget of the video subsystem must be balanced between the copy/scale operation and the video decompression operation. Both operations should be performed thirty times a second for smooth, natural motion video. The division of the performance budget is usually done to worse case which results in an allocation of sufficient performance for a full screen motion video copy/scale operation with the remaining performance being dedicated to the video decompression operation. If the number of pixels (and/or bytes) that have to be written in the copy/scale operation are increased, the performance of the video decompression necessarily decreases. In ever increasing resolutions, for a given level of video technology, a point will be reached where the video image starts to degrade because the information content in the decompressed image is too low. Increasing the resolution beyond this point would be analogous to playing back a poor copy of a VHS tape on the most expensive, highest-quality TV available; the TV would reproduce the low-quality images perfectly.
Several formats have been presented for storing pixel data in a video subsystem. One approach is to simply have 24 bits of RGB information per pixel. This approach yields the maximum color space required for video at the expense of three bytes per pixel. Depending on the number of pixels in the video subsystem, the copy/scale operation could be overburdened.
A second approach is a compromise of the 24 bit system and is based on 16 bits of RGB information per pixel. Such systems have less bytes for the copy/scale operation but also have less color depth. Additionally, since the intensity and color information are encoded equally in the R, G and B components of the pixel, the approach does not take advantage of the human eye's sensitivity to intensity and insensitivity to color saturation. Other 16 bit systems have been proposed that encode the pixels in a YUV format such as 6, 5, 5 and 8, 4, 4. Although somewhat better than 16 bit RGB, the 16 bit YUV format does not come close to the performance of 24 bit systems.
The 8 bit CLUT provides a third approach. This method uses 8 bits per pixel as an index into a color map that typically has 24 bits of color space as the entry. This approach has the advantages of low byte count and 24 bit color space. However, since there are only 256 colors available on the screen, image quality suffers. Techniques that use adjacent pixels to "create" other colors have been demonstrated to have excellent image quality, even for still images. However, this dithering technique often requires complicated algorithms and "custom" palette entries in the DAC as well as almost exclusive use of the CLUT. The overhead of running the dithering algorithm must be added to the copy/scale operation.
One approach for storing pixel data in a video subsystem has been to represent the intensity information with more bits than is used to represent the color saturation information. The color information is subsampled in memory and interpolated up to 24 bits per pixel by the display controller as the information is being displayed. This technique has the advantage of full color space while maintaining a low number of bits per pixel. All of the pixel depth/density tradeoffs are made in the color saturation domain where the effects are less noticeable.
Motion video can be displayed in a 4:1:1 format called the "9 bit format". The 4:1:1 means there are 4 Y samples horizontally for each UV sample and 4 Y samples vertically for each UV sample. If each sample is 8 bits then a 4.times.4 block of pixels uses 18 bytes of information or 9 bits per pixel. Although image quality is quite good for motion video the 9 bit format may be deemed unacceptable for display of high-quality stills. In addition, it was found that the 9 bit format does not integrate well with graphics subsystems. Other variations of the YUV subsampled approach include an 8 bit format.
As noted above, the requirements for a graphics system include high horizontal and vertical resolution with shallow pixels. A graphics system in which the display was 1280.times.1024 with 8 bit clut pixels would likely meet the needs of all but the most demanding applications. In contrast, the requirements for the video system include the ability to generate 24 bit true color pixels with a minimum of bytes in the display buffer. A video system in which the display was 640.times.512.times.8 bit (YUV interpolated to 24 bits and upsampled to 1280.times.1024) would also meet the needs of most applications.
Systems integrating a graphics subsystem display buffer with a video subsystem display buffer generally fall into two categories. The two types of approaches are known as Single Frame Buffer Architectures and Dual Frame Buffer Architectures.
The Single Frame Buffer Architecture (SFBA) approach consists of a single graphics controller, a single digital to analog converter (DAC) and a single frame buffer. In its simplest form, the SFBA has each pixel on the display represented by bits in the display buffer that are consistent in their format regardless of the meaning of the pixel on the display. In other words, graphics pixels and video pixels are indistinguishable in the frame buffer RAM. An integrated SFBA graphics/video subsystem does not address the requirements of the video subsystem very well.
Full screen motion video on an SFBA graphics/video subsystem requires updating every pixel in the display buffer preferably 30 times a second. Assuming the size of the display buffer is on the order of 1280.times.1024 by 8 bits, the rate required for updating every pixel in the display buffer 30 times per second is 1280.times.1024.times.30 or over 30 Mbytes per second. Even without the burden of writing over 30 Mbytes per second to the display buffer, it has been established that 8 bit video by itself does not provide the required video quality. This means the SFBA system can either move up to 16 bits per pixel or implement the 8 bit YUV subsampled technique. Since 16 bits per pixel will yield over 60 Mbytes per second into the frame buffer, it is clearly an unacceptable alternative.
A high quality visual system must be able to mix video and graphics together on a display which requires the display to show on occasion a single video pixel located in between graphics pixels. Because of the need to mix video and graphics there is a hard and fast rule dictating that every pixel in the display buffer be a stand-alone, self-sustaining pixel on the screen. The very nature of the 8 bit YUV subsampled technique makes it necessary to have several 8 bit samples before one video pixel can be generated, making the technique unsuitable for the SFBA visual system.
The second category of architectures integrating video and graphics is the Dual Frame Buffer Architecture (DFBA). The DFBA visual system involves mixing two otherwise free-standing single frame buffer systems at the analog back end with a high-speed analog switch. Since the video and graphics subsystems are both single frame buffer designs each one can make the necessary tradeoffs in spatial resolution and pixel depth with almost complete disregard for the other subsystem. DFBA visual systems also include the feature of being loosely-coupled. Since the only connection of the two systems is in the final output stage, the two subsystems can be on different buses in the system. The fact that the DFBA video subsystem is loosely-coupled to the graphics subsystem is usually the overriding reason such systems, which have significant disadvantages, are typically employed.
DFBA designs typically operate in a mode that has the video subsystem genlocked to the graphics subsystem. Genlocked in this case means having both subsystems start to display their first pixel at the same time. If both subsystems are running at exactly the same horizontal line frequency with the same number of lines, then mixing of the two separate video streams can be done with very predictable results. Since both pixel streams are running at the same time, the process can be thought of as having video pixels underlaying the graphics pixels. If a determination is made not to show a graphics pixel, then the video information will show through. In DFBA designs, it is not necessary for the two subsystems to have the same number of horizontal pixels. As an example, it is quite possible to have 352 video pixels underneath 1024 graphics pixels.
The decision whether to show the video information or the graphics information in DFBA visual systems is typically made on a pixel by pixel basis in the graphics subsystem. A technique often used is called "chroma keying". Chroma keying involves detecting a specific color (or color entry in the CLUT) in the graphics digital pixel stream. Another approach referred to as "black detect", uses the graphics analog pixel stream to detect black, since black is the easiest graphics level to detect. In either case, keying information is used to control the high-speed analog switch and the task of integrating video and graphics on the display is reduced to painting the keying color in the graphics display where video pixels are desired.
There are several disadvantages to DFBA visual systems. The goal of high-integration is often thwarted by the need to have two separate, free-standing subsystems. The cost of having duplicate DACs, display buffers, and CRT controllers is undesirable. The difficulty of genlocking and the cost of the high-speed analog switch are two more disadvantages. In addition, placing the analog switch in the graphics path will have detrimental effects on the quality of the graphics display. This becomes an ever increasing problem as the spatial resolution and/or line rate of the graphics subsystem grows.
It is an object of the present invention to provide an integrated system for storing and displaying graphics and video information.
It is further object of the present invention to provide a system for storing and displaying either graphics or video information, which system can be easily upgraded into an integrated system for storing and displaying graphics and video information by merely augmenting the system with additional memory.
It is another object of the present invention to provide an integrated system for storing and displaying visual information in which different data transfer addresses can be generated to access different types of visual data.
Further objects and advantages of the invention will become apparent from the description of the invention which follows.